之前談到效能改進時,有個關鍵點可以決定事倍功半或是事半功倍:「是否有利用工具去對系統內部做量測?」
很多時候,因為關鍵的性質難以量測或是預測,取而代之的替代方案就是:「假設已知性質 X 與性質 Y 有正相關,而性質 X 難以量測,但是性質 Y 容易量測,就把量測 Y 的結果視為量測到 X 又或是來預測 X。」當上述 X 與 Y 的相關性極高時,這樣子的變通之道還勉強可行,而實際上,隨著時間的前進,X 與 Y 的相關性到底還剩多少,很多人也搞不清楚了。以雇用員工這件事來講,常見的學歷主義,可以視為是一種透過學歷與員工生產力表現的正相關而做出的變通之道。
因為上述的現象,當變通之道量測的誤差愈來愈大時,一旦可以找出某種新的量測方法,可以取得更精準的量測,這個新的方法就可以帶來極高的價值,因為它甚至有機會可以導正一些扭曲的制度。
以下會來探討一些量測生產力相關因子的分析方法。
有一回與朋友聊天,朋友提到他的前公司是一間 IT 服務公司,年營收 3 億台幣,員工 150 人,而該公司的經營者為了要拼股票上市,還在積極設法擴張。我聽完後做了一些試算,覺得有點不妙,只能說,恭喜我朋友離職了。
該公司的人均生產力,即年營收除以員工人數,為 200 萬台幣。如果只看員工人數 150 人,這已經接近了大企業的經營規模,但是,如果也看人均生產力的話,這個人均生產力則是遠遠低於大企業的平均水準。
台灣經濟部中小企業處的報告「中小企業發展面臨問題與因應對策」之中有 2016 年的人均生產力統計數字:
這邊衍生了一個重要問題,企業應該先做設法做大、還是設法提高人均生產力?絕大多數的時刻,設法提高人均生產力才是正確的方向。甚至更直接一點來說,企業往往是因為人均生產力高,才有辦法長大;而不是因為長大了之後,人均生產力容易提高。
人均生產力是企業管理的重要指標,活用這個指標可以有效地提醒企業,內部是否充斥著不能產生(投資報酬率)的計畫。
在企業來講,業務人員的績效通常最容易量測,因為與銷售數字高度相關,另一方面,研發人員的效能光是如何定義,都是一大問題。而軟體開發團隊的運作效能該如何量測、評估,更是沒有客觀的標準,多數的時候,主管也只是憑感覺來做評估。
DORA 研究計畫 提出了一組「四項關鍵指標」框架,而這四項指標與軟體開發團隊的運作效能好壞,有明顯的代表性與關聯性,足以做為重要的參考標準。這四項指標分別是:
此處有兩件事值得我們特別注意,足以做為設計指標來量測其它不同型態工作的原則:
下圖是與四項關鍵指標相關的因果關系圖。
在軟體開發的領域,由於人會犯錯、規格不夠明確等因素,軟體系統在設計時,總是會有沒有設計良好的部分,而且這些不良部分會在日後導致軟體開發速度減慢。這些設計不良又稱之為技術債,暗喻著:「你不花時間去修正它們,你就得一直付出時間利息。」
許多軟體工程師都在職涯之中面對兩個難題:
那有沒有什麼客觀的參考標準,可以做為投資時間來改善技術債的準則呢?Your Code as a Crime Scene 就提出了技術債相關的分析法。
參考下圖,很多的軟體專案,即使程式語言不同,程式碼還是會有相似的結構: